OMU トラブルシューターの初仕事
概要
あなたの友人の A さんは、図1に示すネットワークを構築しました。このネットワークは以下のような設定がなされています。
- 各ルータ間はスタティックルーティングを行っている
 pcからsrv01とsrv02にアクセスできるsrv01とsrv02間はアクセスできない

図1
次に、rt01 と rt03 を直接接続することで、 pc から srv02 へのアクセスのレイテンシを改善できるのではないかと考えました。ネットワーク構成を図2のように変更しようとしています。
- 各ルータが OSPF で接続されている
 

図2
しかし、設定を間違えてしまい、pc から各サーバへアクセスできなくなってしまいました。
あなたは A さんに代わって、ダイナミックルーティングを使用したネットワークに変更してください。
また、A さんは以下のメモを残しています。
- ダイナミックルーティングに移行するにあたって、いくつかスタティックルーティングの設定を削除した。
 - srv01 と srv02 の通信を拒否するために、rt03 に ufw というコマンドでファイアウォールを設定した覚えがある。
 
前提条件
- スタティックルートの経路は追加しないこと
 - 全てのホストに割り当てられた IP アドレスを変更してはいけない
 - 接続可能なホストには、
192.168.1.0/24の接続用アドレスが割り当てられている srv01にファイアウォールを設定してはいけない
初期状態
pcからsrv01およびsrv02へアクセスできない
終了状態
pcからsrv01およびsrv02へアクセスできるpcからsrv02への経路は、pc -> rt01 -> rt03 -> srv02となるsrv01からsrv02へはアクセスできない- ダイナミックルーティングを用いた経路交換がなされている
 
補足
ルータの設定
rt01, rt02, rt03 では、FRRouting を用いて OSPF が動いています。次のコマンドで FRR の設定を行うことができます。
sudo vtyshコマンド例
# 現在の設定を表示する
show running-config
# vtysh を終了する
exit解説
この問題は、OSPFの設定を行ったにも関わらず、期待どおりに経路交換が行われない、というものです。
この問題では3つの設定ミスが複合して発生しています。
rt01に不必要なスタティックルートの設定があるrt01,rt02の OSPF の設定において、router-id が重複しているrt03に誤ったファイアウォールの設定がある
このため、これら3つ全てを解決することで、終了状態を満たすことができます。
想定していた解法
1.
rt01 と rt02 の間で router-id が重複しないように設定する必要があります。
ここでは rt02 の router-id を 2.2.2.2 に変更します。
sudo vtysh
rt02# configure
rt02(config)# router ospf
rt02(config-router)# ospf router-id 2.2.2.2
For this router-id change to take effect, use "clear ip ospf process" command
rt01(config-router)# endなお、この後設定を適用するためには、vtysh内での clear ip ospf process, clear ip ospf neighbor <neighbor> といったコマンドの実行や、 sudo systemctl restart frr など、何らかの形でOSPFのプロセスやネイバーを再起動/再接続する必要があります。
2.
rt01 の FRRouting のコンフィグを確認すると、次のスタティックルートの経路を確認できます。
ip route 172.16.40.0/26 172.16.0.2恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、pc から srv02 までの経路がpc -> rt01 -> rt02 -> rt03 -> srv02 となっています。
次のようにコマンドを実行することでトラブルとなっている経路を削除できます。
rt02# configure
rt02(config)# no ip route 172.16.40.0/26 172.16.0.23.
rt03 のufwのstatusを確認すると、次の設定を確認できます。
user@rt03:~$ sudo ufw status numbered
Status: active
     --                         ------      ----
[ 1] 22                         ALLOW IN    192.168.0.0/16
[ 2] 80                         ALLOW IN    172.16.0.0/24恐らく、A さんの以前の設定が残っているのでしょう。
この設定により、OSPFのパケットの交換が行えなくなっています。
次のようにコマンドを実行することで、OSPFのパケットを受信することが可能となります。
sudo ufw del 2sudo ufw route deny from 172.16.30.0/27 to 172.16.40.0/26sudo ufw default allowsudo ufw reload
なお、他にも /etc/ufw/before.rules でプロトコル番号89の通信を許可する、自身のアドレスとマルチキャストアドレス宛のパケットを許可するなどでもOSPFのパケット交換を可能とすることができます。
採点基準
pcからsrv01へアクセスできる- +30%
 
pcからsrv02へアクセスできる- +20%
 
pcからsrv02へアクセスでき、srv01からsrv02へアクセスできない- +20%
 
pcからsrv02への経路は、pc -> rt01 -> rt03 -> srv02となる- +20%
 
- 完答ボーナス
- +10%
 
 - スタティックルートの経路を追加
- -100%
 
 - 全てのホストに割り当てられた IP アドレスを変更してはいけない
- -100%
 
 
講評
この問題は3つの原因が複合して発生したものであり、3つ全てを解決しないと満点解答とならない問題でした。
更に、OSPFとファイアウォールの組み合わせということもあり、ある程度難しい問題と考えて出題しました。
この問題で満点解答を提出したチームは6チームあり、大凡想定通りの難易度となったかなと感じています。
このトラブルの3つの原因の中ではスタティックルートの修正が最も簡単なものかとは思いますが、この箇所について気づいていない解答が多かったように感じます。
また、 rt03 におけるufwの設定にて、マルチキャストアドレス宛パケットの受信のみを許可し、ユニキャストでのパケット受信は拒否したままの解答が存在しました。
こちらについては、終了状態を満たし正常に通信が可能であること、採点基準において減点対象とならないことから、満点としました。
しかし、通信状態として必ずしも適正であるとはいえないため、実際に設定する際はユニキャストアドレスでの受信を許可するルールも必要となります。